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An EVACS Simulation with Nested Transactions 


1. Introduction 

This report documents the recent effort of the MISSION Kernel Team on an EVACS simulation 
with nested transactions. The team has implemented the EVACS simulation [Atkinson92] along 
with a design for nested transactions. The EVACS simulation is a project wide aid to exploring 
Mission and Safety Critical (MASC) applications and their support software. For this effort it 
served as a trial scenario for demonstrating nested transactions and exercising the transaction 
support design. 

The EVACS simulation is a simulation of some aspects of the Extra-Vehicular Activity Control 
System (EVACS), in particular, just the selection of communication frequencies. Its current 
definition is quite narrow, serving only as a starting point for prototyping purposes. (EVACS 
itself may be supplanted in a larger scenario of a lunar outpost with astronauts and a lunar rover). 

Initially the simulation of frequency selection was written without consideration of nested 
transactions. This scenario was then modified to embed its processing in nested transactions. To 
simplify the prototyping effort, only two aspects of the general design for transaction support have 
been implemented: the basic architecture and state recovery. 

The simulation has been implemented in the programming language Smalltalk. It consists of three 
components: 

• Simulation support code which provides the framework for initiating, interacting and 
tracing the system. 

• The EVACS application code itself, including its calls upon nested transaction support. 

• Transaction support code which implements the logic necessary for nested transactions. 

Each of these components deserves further description, but for now only the transaction support 
will be discussed. 


2. A Transaction Taxonomy and O verview 

An understanding of nested transactions comes from a progressive set of definitions. It begins 
with a relatively simple notion of actions and objects and adds complexity in several incremental 
steps. These steps include adding robustness to actions to form transactions, adding distribution to 
transactions and adding hierarchical nesting to transactions. 

An action is a hierarchical composition of primitives (reads & writes) affecting several "objects 
and which preserves system consistency. In its simplest form, an action is simply a read or write 
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primitive affecting one object. More generally it consists of many reads and writes, affects many 
objects, and may be hierarchically composed of sub-actions. A primitive action inherently 
preserves consistency since it only affects one object. More complex combinations of primitives 
must preserve an overall consistency of system state in order to be properly considered as 
"actions". 

An object, in this case, is a part of, or partition of, the total system state. In our primary reference 
on transactions [Moss85], an object is defined as a data item, but this concept of an object 
generalizes quite well to that of current object oriented definitions. A system is conveniently 
considered to consist of a collection of cooperating objects, each with potentially active and passive 
processing associated with them. An action can be equivalently defined as a unit of processing (a 
method or procedure) which interacts with many objects and which preserves a measure of 
consistency through its execution. Defining the measures of consistency, the steps which preserve 
consistency as well as the combinations of steps which may violate consistency temporarily, is an 
essential part of reliable system design. 

A transaction is an action which exhibits failure atomicity and serializability. These two constraints 
provide the basis for constructing reliable systems out of multiple interacting actions. Failure 
atomicity refers to the property of either completing successfully or having no effect at all. This 
implies in the case of failure the restoration of objects which may have been altered during the 
transaction prior to the detection of failure. In practice, this can be achieved in many ways. 
[Moss85] describes two approaches as recovery from saved state and recovery via undo's, and 
presents details for the first of these which we will adopt. Maintaining recovery states is related to 
the technique of checkpointing known correct values as a computation proceeds. Recovery states 
are maintained in secondary storage which, depending on the degree of reliability required, may be 
itself duplicated or otherwise designed to maintain integrity (elsewhere referred to as stable storage 
or permanent storage). 

Serializability refers to the nature of multiple actions which may interact through concurrent 
execution. If they are serializable, then one can establish after their completion a state which is 
equivalent to that which would be arrived at through some serial execution of the transactions. 
Stated another way, actions are serializable if they incorporate some mechanism of coordination 
which prevents their mutual corruption. Again this can be achieved in several ways. [Moss85] 
defines two approaches as access locking and timestamping with subsequent resolution. The 
approach we have taken uses access locking to ensure that a proper ordering of execution is 
achieved. 

Object locking for transaction serialization is an extension to the common rules of locking for 
concurrency control. First note that we have chosen simple object reads and writes as primitives, 
thus the locking rules are for read/write access control. A read request is granted if no write 
request has been granted. A write request is granted if no other request, read or write, has been 
granted. Proper serializability requires further that no granting of access is released until all access 
is released when the action completes. 
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In summary, our approach to transactions requires the use of secondary storage to implement 
failure atomicity (recovery from failures as if the transaction never executed) and specialized object 
locking to ensure serializability (concurrent actions do not interfere). 

A distributed transaction is a transaction which effects multiple objects at multiple sites. It adds to 
the paradigm of transaction processing the ability to recover from multiple and independently 
fallible processors and failed communications. Note that distribution of objects participating in a 
transactions does not require a change or extension to our general definition of transactions, i.e., 
distributed transactions obey the same rules for failure atomicity and serializability. Only the 
processing required to implement such transactions is modified. The modification consists of the 
addition of a two-phase commit protocol to ensure that all objects involved in the transaction are 
updated or reverted consistently. 

The two-phase commit protocol requires that each participant object involved in the transaction first 
prepare to commit and respond that it is in fact prepared. Following successful processing of the 
preparation phase the transaction coordinator can logically toggle its own records to indicate 
commitment and broadcast this to all participants in the commitment phase. In this way, prior to 
commitment any participant not able to commit forces an abort. Following preparation all 
participants are able to fall forward or backwards. It is the singular action of the coordinator which 
transitions the transaction to commitment. Participants must then wait for the coordinator to signal 
which action they should take. In this way, assuming all node and communications failures are 
recoverable, no unrecoverable inconsistency of commitment or failure of the transaction can occur. 

The Alpha kernel [Northcutt87] introduced, and we will assume for Mission as well, that all 
objects are truly independent; objects and messages can fail even though no physical distribution or 
node failure is involved. Thus, for the purposes of transaction processing, each object essentially 
becomes its own "virtual node". As a consequence of this perspective, any transaction requires the 
logic of distributed transactions (i.e., two-phase commits). Each object must handle its own 
participation in the transaction (i.e., handle enter_transaction, prepare_to_commit, 
complete_commit and abandon_transaction messages). 

The final complexity which we add to this discussion is that of nested transactions. Nested 
transactions add the same feature of hierarchical composition as was defined for actions, allowing 
nested actions to be defined as nested transactions. The advantage of nested transactions is the 
partitioning of work being done which may require retries or alternative processing in the face of 
failure. If all processing which must commit or fail together must be executed as a single 
transaction, then failure requires reprocessing of the entire transaction. If instead the processing is 
broken into several sub-transactions, then failure of one sub-transaction can be handled 
independently of the other sub-transactions before signalling failure of the entire transaction. We 
still have the property that if the top-level transaction fails then all participants are restored as if no 
processing occurred, and we have the same property for the sub-transactions which allows for 
consistency of recovery within the transaction as well. 
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The introduction of nested transactions alters the general handling of transactions in two ways. 
First, the object locking rules must be modified to ensure proper coordination throughout the 
transaction and within the transaction. Secondly, recovery of nested transactions requires 
essentially a stack of recovery values being kept. 

The change to the object locking rules relates to the handling of subtransaction completion. In 
normal transaction processing all object access required by the transaction is held until the 
transaction completes, and is then released. In the case of a subtransaction, the access restriction 
must be held until the entire top-level transaction completes. This is handled by having the sub- 
transaction pass the object lock to its parent transaction for it to hold until completion. The parent 
may then pass the lock to its parent, if present, and so on until the top-level transaction is reached. 

The second change to the object locking rules relates to the granting of access. Again, normal 
transaction access rules address "peer" level transactions attempting to access the same object. A 
special case exists if a subtransaction attempts to access an object which has already been accessed 
within a superior (e.g. parent) transaction. This can occur in two ways. It may be (a) that the 
object is required directly by a superior transaction and by the subtransaction, or it may be (b) that 
the object was required for a previous subtransaction. Case (a) is a difficult situation since it is not 
clear whether the superior transaction has completed its access in a consistent way at the time of the 
subtransaction's request for access. Unfortunately it is difficult to distinguish at runtime case (a) 
from case (b). Thus it is left either as a constraint on the programmer, as a constraint of the 
language, or to other pre-runtime controls not to implement case (a). 

Case (b) is actually quite normal and acceptable. It requires, however, that the locking rules be 
defined to accommodate it. Note that at the end of the first subtransaction the object lock was 
passed up to the parent transaction. Thus when, during the second subtransaction, access to the 
object is requested the lock is owned by its parent. In this case, should be granted based on the 
possession of the lock by the parent. Generalized, the locking rules can be extended to the 
following: 

• allow read access if all transactions holding a write lock are superiors of the subtransaction 
making the request, and 

• allow write access if all transactions holding a lock in any mode are superiors of the 
subtransaction making the request. 

The last note on nested transactions addresses the multiple levels of recovery required. For single 
level transactions a single recovery state is necessary for restoration. In the case of nested 
transactions, an object may be involved in several levels of nested transactions (e.g., case (b) just 
described). In fact, the rules of transaction participation and object locking prevent an object from 
participating in multiple transactions except when nested. Because an object may need to recover 
from a subtransaction failure prior to recovery from the parent transaction failure, a recovery state 
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is necessary for the nested levels an object participates in as well as for the outer-most transaction 
level. A basic stack of recovery states meets this requirement. 
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3. A Design for Transaction Support 


Our transaction design is based on two class definitions; objects of interest are either transaction 
managers or transaction participants. The application itself is defined as objects which inherit from 
the transaction participant class. This implies every application class is a subclass of the 
transaction participant class. The full processing of distributed nested transactions is incorporated 
into the definitions of these two object classes. This functionality includes two-phase commit, 
uniform recovery, concurrency control (lock management), lost-participant and manager recovery 
and schedulability / deadlock resolution. However, for the current prototype only the general 
architecture and recovery processing were implemented. 

Note that the design was conceived with the idea in mind to eventually merge transaction semantics 
into the programming language itself. As a consequence and in consideration of existing languages 
(e.g., Smalltalk, Ada, Dragoon), it assumes a reasonable transformation of a "naive" application to 
one which incorporates transaction processing. 

Transaction managers are defined to coordinate transaction participants and any subtransactions 
which are defined. Other than keeping a record of these participants and subtransactions, 
transaction managers are principally responsible for implementing the coordinator logic of two- 
phase commits as was described earlier. Transaction participants are defined to participate in 
transactions and, in particular, potentially nested transactions. Transaction participants are 
responsible for saving their current state, maintaining a stack of recovery states (in stable storage 
which can survive system crashes) and for properly responding to the various method calls 
associated with transactions: enter, prepare_commit, complete_commit and abandon_transaction. 

The treatment of nested transactions deserves some special comment here. Our implementation of 
the transaction manager accommodates the situation of being nested within another transaction, but 
in general defines the processing to be identical for a sub-transaction as for a top-level transaction. 
This is possible partly because the treatment of state saving and recovery is handled by the 
participants. The singular addition required of a nested transaction manager is the passing of the 
participants list to the parent transaction manager. 

Our design focuses more processing on the transaction participant. In particular, it is left to the 
participant to implement its own methods for saving and restoring its state. The transaction 
manager coordinates processing by issuing prepare_to_commit, complete_commitment or 
abandon_transaction commands, but does not receive or transmit participant states. Each 
participant thus keeps its own recovery stack. 

A particularly significant aspect of the design is the dynamic nature of object participation. Objects 
participate in transactions when they are called upon, without any predefined list of participants 
being given to the transaction manager in advance. The process of entering into a transaction 
occurs as a part of calling an object. Prior to initiating the particular method of the call, the general 


MISSION 

EVACS Simulation Report 


6 


6/30/92 



transaction entry code is executed. Once entered, the object is a participant until the end of the 
transaction. The corresponding processing for leaving a transaction occurs at transaction 
commitment or abort. 

Entering a transaction generally requires the saving of the current state of the object as a new entry 
on the recovery stack and notifying the transaction manager of the new participant. This is only 
done, however, if the object has not already participated in this transaction. The recovery state 
must always be the state of the object before any involvement in the transaction. To insure the 
recovery state is saved only once, a record is kept of the current transaction by each object. Thus 
as a part of transaction entry a comparison is made between the calling transaction and the current 
transaction. Only if they are different (the calling transaction is a subtransaction of the current 
transaction) is the state saved. 

As was noted already, an object leaves a transaction at the time of transaction commitment or abort. 
Leaving a transaction implies poping the stack of recovery states. If the transaction commits the 
recovery value is tossed away. If the transaction aborts, the object assumes the recovery state as 
its current state, abandoning its previous current state. 

There is a special case of leaving a nested transaction. If the transaction being left is nested (has a 
parent), then the object must be entered into the parent transaction. Again an entry check is made if 
the object had previously participated in the parent transaction. If this is the case then no further 
action should be taken. The object already has a recovery value from its earlier participation in the 
parent transaction on the stack which was made current when the subtransaction's recovery stack 
was popped. 

If the object had not previously participated in the parent transaction (the subtransaction was first to 
call upon the object) then an entry into the parent transaction must take place. Note, however, that 
the recovery state to be pushed on the stack is the state of the object before its involvement in the 
subtransaction. This is the recovery value normally popped upon leaving the transaction. In fact, 
the recovery state needn't be popped at all (only to be pushed again), the recovery value can simply 
be left in place. 

This processing ensures that all participants are kept in synchrony with the nesting of transactions 
which they are involved in. The recovery stack is not necessarily as deep as the nesting of 
transactions because the participants may not be entered into parent transactions until after a 
subtransaction commits or aborts. The process of being entered into the parent transaction as a part 
of leaving a nested transaction ensures that the proper set of recovery values is being maintained 
for each participant. 
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Evacs Simulation in SmallTalk 


if 

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ft*************************** 

Application : EVACS Simulation — modified to include transactions 

A simulation of some aspects of the Extra-Vehicular Activity Control System 
(EVACS) . In particular, this simulation looks only at the interaction between a 
central controller and a set of MMUs, and more specifically at the selection 
of communication frequencies. The simulation has been extended to implement 
frequency changes as a set of nested transactions. Changes must uniformly affect 
both base station antennas and the Manned-Manuvering-Units (MMUs) . Different 
scenarios of transaction success and failure can be run by having different 
subtransactions of the scenario succeed or fail. 

The simulation allows user control by the choice of frequency. Each digit of the 
three digit frequency controls one of the elements in the simulation and the 
subtransactions it participates in. In general values less than 5 succeed while 
values 5 or greater fail. 

Digit 1 affects the central controller. 

Digit 2 affects the MMU. 

Digit 3 affects the antenna manager. 

Also, digit 3 controls the antenna manager* s antenna array. These antennas 
succeed if digit 3 is 4 or 5, but fail otherwise. For example: 

114Hz is complete success, 

914Hz is failure only of the central controller (root transaction) 

Classes : EvacsRoot 

Transact ionManager PermanentStore 
Transact ionParticipant 
Evacs 

SimWindow TextDisplayer TextDisplayPane 
CentralController MMU AntennaMgr Antenna 
EvacsStack 

Example : (Evacs new) start. 

Classes are grouped into three categories: 

Transaction support. 

Simulation support, and 
Evacs application definition. 

Classes definitions are presented in this order, then the class and instance 
method definitions in the order: 

Simulation support, Evacs application definition. Transaction support 
which more closely presents the methods top-down in order of exection 
★★**★★★***★*★*★★**★★★★*★*★★★★★*★**★★*★★***★★★★★**********★*★★** *★**★★*******★★ 

" t 
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Evacs Simulation in SmallTalk 
(class definitions) 


" Transaction Support Classes " ! 

Object subclass: #EvacsRoot 
instanceVariableNames: ' 1 

classVariableNames : ' ' poolDictionaries: ' ' 

” an empty class, no protocol or representation 
collects subclasses into one parent 

« i 

EvacsRoot subclass : #TransactionManager 

instanceVariableNames: ’id participants status 

transactionHierarchy subTs 1 
classVariableNames: 11 poolDictionaries: 11 
,f serves to coordinate transaction 2-phase commit and abort 
Class Methods 

runAsNewTransaction: id: parent : receiver : 

Instance Methods 

initWithID : , setParents : , processingComplete, abort, 
registerParticipant : , inheritParticipants: , registerSubTransaction: , 
transactionHierarchy, status 

" ! 

EvacsRoot subclass : #TransactionParticipant 

instanceVariableNames: ' currentTM permanentStore status ' 
classVariableNames: 11 poolDictionaries: ' ' 

" provides protocol and representation for objects which participate in 
transaction 
Class Methods 
new 

Instance Methods 

init, currentState, setStateTo:, addState:, restoreState : , prepared 
enter: , prepareCommitment, completeCommitment, abandonTransaction 

" ! 

EvacsRoot subclass: #PermanentStore 

instanceVariableNames: f currentState recoveryStack * 
classVariableNames: 1 1 poolDictionaries: 1 * 

" provides facility for saving an object's state & recovery states 
Class Methods 
new 

Instance Methods 

init, push:, update:, pop, readCurrent, readTop 

»» i 
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Evacs Simulation in SmallTalk 
(class definitions) 


" Simulation Support Classes " ! 

OrderedCollection subclass : #EvacsStack 

instanceVariableNames : 1 1 classVariableNames: 1 * poolDictionaries: * 1 
" subset of and renaming of OrderedCollection methods , no new representation 
Class Methods (none) 

Instance Methods 

push : , pop, pushAll : , readTop 

” ! 

TransactionParticipant subclass : #Evacs 

instanceVariableNames: 1 simWindow controller 1 
classVariableNames: 11 poolDictionaries: 11 
" Collects subclasses into parent. Defines shared representation 
(all subclasses get a reference to simWindow and controller) . 

Defines method to initiate a simulation (start) 

All subclasses are potential transaction participants 

" j 

TextEditor subclass: #TextDisplayer 

instanceVariableNames: 1 1 classVariableNames: 1 f poolDictionaries: 1 1 
" modified TextPane dispatcher, method modify always returns false 
(closing will not ask to have changes saved) , no other changes 

" ! 

TextPane subclass: #TextDisplayPane 

instanceVariableNames: 1 1 classVariableNames: 1 1 poolDictionaries: 1 1 
" modified TextPane, defaultDispatcherClass returns TextDisplayer 
no other changes 

" I 

Evacs subclass: #SimWindow 

instanceVariableNames: 1 controllerFreq antennaFreq mmuFreq inputPane 

msgStream displayPane 1 

classVariableNames: 11 poolDictionaries: 

" Provides the display and interaction model for the simulation. 

Creates the window, panes (Input, Msg and Display) and menus objects 
Class Methods (none) 

Instance Methods 

externally called methods 

openWith, antennaFreq: , controllerFreq: , 
anMMUFreq : , text Out : 

internally called methods (called by window panes created by openWith) 
inputMenu, nullMsg, defaultlnput, displaySim: 
promptForFreq, takeNewFreq, callController : 

» i 
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Evacs Simulation in SmallTalk 
(class definitions) 


" EVACS application classes " ! 

Evacs subclass: #CentralController 

instanceVariableNames : 'mmuArray antennaMgr frequency mmusCount* 

classVariableNames: 11 poolDictionaries: 11 
H models the central controller (at base station) for the Evacs application 
Class Methods (none) 

Instance Methods 

setMaxMMUs : andSimWindow : , current State, setStateTo: , prepared, 
registerMMU : , changeFreq: 

« | 

Evacs subclass: #MMU 

instanceVariableNames: frequency number 1 
classVariableNames: 11 poolDictionaries: 

" models behavior of an independent Manned Manuvering Unit 
Class Methods (none) 

Instance Methods 

setController: andSimWindow: , currentState, setStateTo: , prepared, 
changeFrequencyTo : 

H | 


Evacs subclass: #AntennaMgr 

instanceVariableNames : 1 antennaArray f requencyArray 1 
classVariableNames: ! ! poolDictionaries: * 1 
" coordinates a collection of three antennas at the base station 
Class Methods 
newWith: 

Instance Methods 

set SimWindow : andMaxMMUs : , antennaArray 

currentState, setStateTo: , prepared, changeAntennasTo : 

" | 

Evacs subclass: #Antenna 

instanceVariableNames : 1 f requencyArray 1 
classVariableNames: 11 poolDictionaries: 11 ! 

M models behavior of an independent antenna at the base station 
Class Methods (none) 

Instance Methods 

setMaxMMUs : andSimWindow: andController : , 

currentState, setStateTo: , prepared, changeFrequencyOfMMU : 

»« i 
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Evacs Simulation in SmallTalk 
(simulation support) 

! Evacs class methods ! ! 

! Evacs methods ! 

,T Collects subclasses into parent. Defines shared representation 
(all subclasses get a reference to simWindow and controller) . 
Defines method to initiate a simulation (start) 

All subclasses are potential transaction participants 

u 

start 

| maxMMUs | 
maxMMUs := 3. 

simWindow := ( SimWindow new ) . 
controller := ( CentralController new ) 
setMaxMMUs: maxMMUs 
andSimWindow : simWindow . 

( MMU new ) 

setController : controller 
andS imWi ndow : s imW i ndow . 

( MMU new ) 

setController : controller 
andSimWindow : simWindow . 

( MMU new ) 

setController: controller 
andSimWindow : simWindow . 

( simWindow openWith: controller ) . 

i ; 
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Evacs Simulation in SmallTalk 
(simulation support) 


! SimWindow class methods ! ! 

! SimWindow methods ! 

" Provides the display and interaction model for the simulation. 

Creates the window, panes (input, msg and display) and menus objects 
: contollerFreq antennaFreq mmuFreq inputPane msgStream displayPane 
***** externally called methods ***** 

users of SimWindows can openWith, then update frequencies and write out msgs 

i« 

openWith: acontroller 
| topPane msgPane 1 
controller := acontroller. 
controllerFreq : = 1 0Hz 1 . 
antennaFreq : = 1 QHz 1 . 
mmuFreq : = 1 0Hz 1 . 

topPane := (TopPane new) label: 1 Kernel Simulation 1 . 

( topPane addSubpane: 

( inputPane := (TextDisplayPane new) 

model: self; name: #defaultlnput; menu: #inputMenu; 
framingRatio: (0 @ 0 extent: (2/3) 0 (1/4)) )). 

( topPane addSubpane: 

( displayPane := (NoScrollGraphPane new) 
model: self; name: #displaySim: ; 

framingRatio: (0 0 (1/4) extent: (2/3) @ (3/4)) )). 

( topPane addSubpane: 

( msgPane := (TextDisplayPane new) 

model: self; name: tnullMsg; 

framingRatio: ((2/3) @ 0 extent: (1/3) 01) )). 
msgStream := ( msgPane dispatcher ) . 

( (topPane dispatcher) open; scheduleWindow ) . 

i 

antennaFreq : newFreq 
antennaFreq := newFreq. 

( displayPane update ) . 

I 

control lerFreq : newFreq 
controllerFreq := newFreq. 

( displayPane update ) . 

I 

anMMUFreq: newFreq 
mmuFreq := newFreq. 

( displayPane update ) . 

t 

textOut: aString 

( msgStream nextPutAll : aString; cr ) . 

i 

"continued" 
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Evacs Simulation in SmallTalk 
(simulation support) 


" SimWindows methods continued " 

H ***** internally called methods ***** 

called by window panes (created by openWith:) at various times 

inputMenu establishes a menu providing command initiation for the user. 

User interaction in the system consists solely of selection of text in 
the inputPane and/or menu selection. The menu provides two commands, 
implemented here by promptForFreq and takeNewFreq. promptForFreq puts 
up a dialog box for user input. takeNewFreq takes whatever is currently 
selected in the inputPane as the user input. promptForFreq and takeNewFreq 
are the only methods which call out from the window to the model, both 
calling controller .changeFreq 

it 

nullMsg 

A | | 

J 

defaultlnput 

~( 1 999Hz 991Hz 919Hz 914Hz 199Hz 194Hz 119Hz 114Hz 
111Hz 115Hz 911Hz 915Hz ' ) 

i 

inputMenu 

*( (Menu labels: ( 'Prompt for Freq. \Selected New Freq' 

breakLinesAtBackSlashes ) 
selectors : # (promptForFreq takeNewFreq) ) 
title: 'Operations' ) 

promptForFreq 
| input String j 

inputstring := ( Prompter prompt: 'Please type desired frequecy* 

default: '114Hz 1 ). 

( self textOut: ('initiating change to inputstring) ). 

( self callController : inputstring ) . 

I 

takeNewFreq 

| inputstring | 

inputstring := ( inputPane selectedString ) . 

( self textOut: ('change requested, to ', inputstring) ). 

( self callController: inputstring ) . 

I 

"continued" 
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Evacs Simulation in SmallTalk 
(simulation support) 


" SimWindows methods continued " 

callController : msg 

"with transaction code .,.' 1 

| success tm | 

tm := Transact ionManager 

runAsNewTransact ion : 

[ controller changeFreq: msg ] 

id: , promptForFreq=>controller . changeFreq 1 

parent : current TM 

receiver: controller . 
success := ( (tm status) = #completed ) . 

( self textOut: (’transaction success: (success printstring)) ). 

j 

displaySim: aRect 

| aPen afont aForm | 

aForm := ( Form width: 600 height: 400 ) . 
afont : = ( Font applicationFont ) . 
aPen := ( Pen new: aForm ) . 

aPen place: 65 @ 25; 

centerText: ’CCU' font: afont. 

aPen place: 50 @ 50; down; black; 

polygon: 35 sides: 4. 
aPen place: 66 @ 41; 

centerText: controllerFreq font: afont. 

aPen place: 115 @ 75; 

centerText: ’ANT 1 font: afont. 

aPen place: 100 @ 100; down; black; 

polygon: 35 sides: 4. 
aPen place: 116 @ 91; 

centerText: antennaFreq font: afont. 

aPen place: 165 @ 125; 

centerText: ’ MMU ’ font: afont. 

aPen place: 150 @ 150; down; black; 

polygon: 35 sides: 4. 
aPen place: 166 @ 141; 

centerText : mmuFreq font : afont . 

~ aForm. 

i i 
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Evacs Simulation in SmallTalk 
(simulation support) 


! TextDisplayer class methods ! ! 

'.TextDisplayer methods ! 

" modified TextPane dispatcher, method modify always returns false 
(closing will not ask to have changes saved) , no other changes 

modified "user modification not significant" 

* false 

t i 


! TextDisplayPane class methods ! ! 

! TextDisplayPane methods ! 

" modified TextPane, defaultDispatcherClass returns TextDisplayer 
no other changes 

H 

defaultDispatcherClass 
A TextDisplayer 
| ! 
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Evacs Simulation in SmallTalk 
(simulation support) 


! EvacsStack class methods ! ! 

! EvacsStack methods ! 

" subset of and renaming of orderedCollection methods, no new representation 

It 

push: newObject 

( super addFirst: newObject ) . 

i 

pop 

A ( super removeFirst ) 

( 

pushAll : aCollection 

( super addAllFirst: aCollection ) 

I 

readTop 

^ ( contents at: startPosition ) . 

i ] 
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(EVACS application code) 


ICentralController class methods ! ! 

!CentralController methods ! 

11 models the central controller (base station) for the Evacs application 
subclass to: Evacs, subclass to: TransactionParticipant 
for Transaction Participant 
: currentTM permanent Store status 
for Evacs 

: simWindow controller 
for CentralController 

: mmuArray antennaMgr frequency MMUsCount 


setMaxMMUs : maxMMUs 

andSimWindow : aSimWindow 

mmuArray := ( Array new: maxMMUs ) . 

antennaMgr := ( AntennaMgr new ) setSimWindow: aSimWindow 

andMaxMMUs : maxMMUs . 


mmusCount : = 0 . 

simWindow := aSimWindow. 

controller := self. 

( antennaMgr antennaArray ) 

do: [ :anAntenna | 

(anAntenna setMaxMMUs: maxMMUs 

andSimWindow : simWindow 
andController : controller) . 


] 


- ]. 


currentState 

* ( super addState: 

( (Dictionary new) at: #controllerSlot 

put: frequency; 

yourself ) ) . 

t 


setStateTo: state 

( super restoreState : state ) . 

frequency := ( state at: #controllerSlot ) . 

( simWindow controllerFreq: frequency ) . 

i 

prepared 

* ( (frequency at: 1) < $5 ). "1st digit of frequency < 5" 

i 

registerMMU: mmu 

mmusCount : = mmusCount + 1 . 

( mmuArray at : mmusCount put : mmu ) . 

^ mmusCount 

I 

"continued" 
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"CentralController methods continued" 
changeFreq: newFreq 

" Implements the essential function of EVACS sim, that of changing the 
frequencies of the MMUs and antennas in a coordinated fashion. Changes 
are implemented as transactions to ensure integrity. In the EVACS sim 
this method is also called as a top-level transaction thus all 
transactions here and subsequently created are sub-transactions. 

ft 

| anMMU mmuNum tm success | 
frequency newFreq. 
mmuNum : = 1 . 

anMMU := ( mmuArray at: mmuNum ) . 

tm := TransactionManager 

runAsNewTransaction : 

[ anMMU changeFrequencyTo: newFreq ] 
id: 1 controller=>anMMU. changeFreq’ 

parent : currentTM 

receiver: anMMU. 

success := ( (tm status) = #completed ) . 

( simWindow textOut: (’transaction success: (success printstring)) ). 

11 to differentiate the MMUs from the antenna manager if the mmu fails, it 
is renentered into the parent transaction with a dummy value of 000Hz 


(success) 
ifFalse: [ 

( anMMU enter: currentTM ) . 

( anMMU changeFrequencyTo: ’OOOHz’ )]. 

tm : = TransactionManager 

runAsNewTransaction : 

[ antennaMgr changeAntennasTo: newFreq 
for : mmuNum ] 

id: ’ control ler=>antennaMgr . changeFreq’ 

parent : currentTM 

receiver : antennaMgr . 
success := ( (tm status) = #completed ) . 

( simWindow textOut: (’transaction success: * , (success printstring)) ). 

( simWindow controllerFreq: newFreq ) . 

! 1 
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Evacs Simulation in SmallTalk 
(EVACS application code) 


! MMU class methods ! ! 

! MMU methods ! 

11 models behavior of an independent Manned Manuvering Unit 
subclass of Evacs, subclass of TransactionParticipant 
for TransactionParticipant 
: currentTM permanentStore status 
for Evacs 

: simWindow controller 
for MMU 

: number frequency 

M 

setController : theController 

andSimWindow : theSimWindow 

controller := theController. 

number := ( controller registerMMU: self ) . 

simWindow := theSimWindow. 

I 

currentState 

* ( super addState: 

( (Dictionary new) at: #mmuSlot 

put: frequency; 

yourself ) ) . 

] 

setStateTo : state 

( super restoreState : state ) . 
frequency := ( state at: #mmuSlot ) . 

( simWindow anMMUFreq: frequency ) . 

prepared 

* ( (frequency at: 2) < $5 ) . 

I 

changeFrequencyTo : newf requency 
frequency := newf requency . 

( simWindow anMMUFreq: frequency ) . 

( simWindow textOut: 

('This is an MMU and Im changing frequency to 1 , frequency) ) . 

t t 
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Evacs Simulation in SmallTalk 
(EVACS application code) 


! AntennaMgr class methods ! 
newWith : aSimWindow 

* (super new) initWith: aSimWindow 

I i 

! AntennaMgr methods ! 

58 coordinates a collection of three antennas at the base station 
subclass of Evacs, subclass of TransactionParticipant 
for TransactionParticipant 
: currentTM permanentStore status 
for Evacs 

: simWindow controller 
for antennaMgr 

: antennaArray frequencyArray 

it 

setSimWindow : aSimWindow 
andMaxMMUs: maxMMUs 
simWindow := aSimWindow. 

antennaArray := ( Array with: (Antenna new) 

with: (Antenna new) 

with: (Antenna new) ) . 

frequencyArray := ( Array new: maxMMUs ) . 

i 

antennaArray 
^ antennaArray 

I 

currentState 

* ( super addState: 

( (Dictionary new) at: #antennaMgrSlot 

put: (frequencyArray shallowCopy) ; 

yourself ) ) . 

t 

setStateTo: state 

( super restoreState: state ) . 

frequencyArray := ( state at: # antennaMgr Slot ) . 

( simWindow antennaFreq: (frequencyArray at: 1) ) . 

i 

prepared 

( (((frequencyArray at: 1) at: 3) = $4) 

I (((frequencyArray at:l) at: 3) = $5) ). 

j 

"continued" 
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Evacs Simulation in SmallTalk 
(EVACS application code) 

"AntennaMgr methods continued" 

changeAntennasTo : newFreq 
for: anMMU 
| tm anAntenna | 

( f requencyArray at: anMMU put: newFreq ) . 

( 1 to: 3 ) 
do: [ :num | 

anAntenna := ( antennaArray at: num ) . 
tm := Transact ionManager 

runAsNewTransaction : 

[( anAntenna changeFrequencyOfMMU : 1 to: newFreq )] 
id: ' antennaMgr=>anAntenna. changeFreq 1 

parent : currentTM 

receiver : anAntenna . 

] . 

( simWindow antennaFreq: newFreq ) , 

; i 
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Evacs Simulation in SmallTalk 
(E VACS application code) 


! Antenna class methods ! ! 

! Antenna methods ! 

M models behavior of an independent antenna at the base station 
subclass of Evacs, subclass of TransactionParticipant 
for TransactionParticipant 
: currentTM permanentStore status 
for Evacs 

: simWindow controller 
for Antenna 
: frequencyArray 

u 

setMaxMMUs: maxMMUs 

andSimWindow : aWindow 

andController : aController 
frequencyArray := ( Array new: maxMMUs ) . 
simWindow := aWindow. 

controller := aController. 

j 

currentState 

A ( super addState: 

( (Dictionary new) at: #antennaSlot 

put: (frequencyArray shallowCopy) ; 

yourself ) ) . 

i 

setStateTo : state 

( super restoreState: state ) . 
frequencyArray := ( state at: #antennaSlot ) . 

( simWindow textOut : 

('This is anAntenna, change be done to (frequencyArray at: 1)) ). 

( 

prepared 

* ( ((frequencyArray at: 1) at: 3) < $5 ) . 

f 

changeFrequencyOfMMU : number to: frequency 

( frequencyArray at: number put: frequency ) . 

( simWindow textOut: 

('This is anAntenna, change be done to f , frequency) ). 

i t 
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Evacs Simulation in SmallTalk 
(transaction support) 

! TransactionManager class methods ! 
runAsNewTransaction: block 
id: userid 

parent : parentTransaction 

receiver : participantOb ject 

" Creates transaction, executes block within it and invokes completion 
processing. Receiver must be object receiving message in block " 

| newTM | 

newTM := (super new) 

initWithID : userid; 
setParents : parentTransaction . 

( participantOb ject enter: newTM ) . 

( block value ). "execute the transaction's code" 

( newTM processingComplete ) . 

~ newTM 

i I 

! TransactionManager methods ! 

" serves to coordinate transaction 2-phase commit and abort 
: id participants status transactionHierarchy subTs 

initWithID: userid 

" sets user id (string) and initializes collection variables and status 

id := userid. 

subTs : = ( Bag new ) . 

participants := ( Set new ). 

status : = # created . 

i 

setParents : parentTransaction 

" sets transaction hierarchy, including all parents and itself " 
transactionHierarchy := (EvacsStack new) . 

( parentTransaction notNil ) if True: [ 

( transactionHierarchy pushAll: (parentTransaction transactionHierarchy) ). 

( parentTransaction registerSubTransaction: self ) 

] . 

( transactionHierarchy push: self ) . 

i 

" continued. . . " 
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Evacs Simulation in SmallTalk 
(transaction support) 

" transactionManager methods cont. " 
processingComplete 

" initiate two phase commit: send prepare message to all participants 

if participants all prepared, commit and send complete messages " 

| success parentTM | 
status := fpreparing. 
success := true, "for now” 
participants do: [ : participant | 

success := success & ( participant prepareCommitment ) ] . 

(success) 
if True: [ 

status := # committed. " the binary arbiter of commitment ” 

( transactionHierarchy pop ) . 

parentTM := ( transactionHierarchy readTop ) . 
participants do: [ : participant | 

( participant completeCommitment : parentTM ) ] . 

( parentTM notNil ) if True: [ 

( parentTM inheritParticipants : participants ) ] . 
status := tcompleted. 

] 

ifFalse: [( self abort )]. 

I 

abort 

" send abandonTransaction message to all participants " 

status := #aborted. 

participants do: [ participant | 

( participant abandonTransaction ) ] . 


registerParticipant : participantOb ject 

( participants add: participantOb ject ) . 

i 

inheritParticipants : subTparticipants 

( participants addAll: subTparticipants ). 

registerSubTransaction: transactionManager 
( subTs add: transactionManager ) . 

i 

transactionHierarchy 
* transactionHierarchy 

j 

status 
^ status 

i i 
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Evacs Simulation in SmallTalk 
(transaction support) 


! TransactionParticipant class methods ! 
new 

~ (super new) init. 

i t 

! TransactionParticipant methods ! 

" provides protocol and representation for objects which participate in 
transaction 

: currentTM permanentStore status 

it 

init 

permanentStore := ( PermanentStore new ) . 
status := #free. 

t 

currentState "returns state as collection of state information" 

" ( self implementedBySubclass ) " 

^ self addState: (Dictionary new) "subclass state, class state" 

i 

setStateTo: state "sets state to contents of stateCollection" 

" ( self implementedBySubclass ) . " 
self restoreState: state. 

i 

addState: state "adds this class 1 instance variables to state object 
( state at: #participantSlot 

put: (Array with: status 

with: currentTM) ) . 

* state 

j 

restoreState: state "restores this class 1 instance variables" 

| thisClassState | 

thisClassState := (state at: #participantSlot) . 
currentTM := thisClassState at: 2. 
status := thisClassState at: 1. 

t 

prepared "returns true if object is ready to commit" 

"( self implementedBySubclass )." 

* true "by default" 

i 

"Continued" 


MISSION B-19 

EVACS Simulation Report 


6/30/92 



Evacs Simulation in SmallTalk 
(transaction support) 

"TransactionParticipant methods continued" 
enter: enteredTM 
| aCurrentState | 

"enter into transaction, if not current transaction save state” 

( currentTM ~= entered™ ) if True: [ 

( permanentStore push: (self currentState) ). "recovery value" 

status := tinTransaction. 

current™ := entered™. 

( entered™ registerParticipant : self ). 

] • 

( permanentStore update: (self currentState) ) . "current value" 

t 

prepareCommitment 

"check status, if ok prepare for commitment" 

* ( (self prepared) ifTrue: [ 

( permanentStore update: (self currentState) ) . 
status := #prepared. 

1; 

yourself ) 

i 

completeCommitment : parent™ 

( self restoreState : (permanentStore readTop) ). 

"class variables only, not newly calculated subclass variables" 

( parentTM notNil ) 

ifTrue: [ "enter parent transaction" 

" the following is equivalent to leaving the current transaction (pop) 
and entering the parent transaction (push if not current transaction) 
but inverted as an optimization (pop if parent is current transaction) " 
( current™ - parent™ ) 
ifTrue: [ ( permanentStore pop ) . ] 

ifFalse: [ current™ := parent™. 

status := #inTransaction ] 

1 

ifFalse: [ "leave current transaction" 

( permanentStore pop ) 

] • 

! 

abandonTransaction 
| recoveryState I 

recoveryState := ( permanentStore pop ) . 

( self setStateTo: recoveryState ) . 

( permanentStore update : recoveryState ) . 

i i 
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Evacs Simulation in SmallTalk 
(transaction support) 


! PermanentStore class methods ! 

new A (super new) init. 

] ; 

! PermanentStore methods ! 

” provides facility for saving an object’s state & recovery states 
: currentState recoveryStack 

u 

init 

recoveryStack := (EvacsStack new) . 

j 

push : recovery State 

recoveryStack push: recoveryState . 

I 

update : newCurrentState 

currentState := newCurrentState, 

] 

pop A recoveryStack pop 

I 

readCurrent A currentState 

i 

readTop * (recoveryStack readTop) 

I i 


! CentralController methods ! 
changeFreq: newFreq 

| anMMU mmuNum tm success anAntenna | 
frequency : = newFreq. 
mmuNum : = 1 . 

anMMU : = ( mmuArray at: mmuNum ) . 

" regardless of antenna manager’s success or failure, 
antenna 1 will be entered into transaction directly 11 
anAntenna := ( (antennaMgr antennaArray) at: 1). 
tm := Transact ionManager 

runAsNewTransaction : 

[ anAntenna changeFrequencyofMMU: 1 to: newFreq ] 
id: ’ controller=>anAntenna. changeFreq’ 

parent : currentTM 

receiver : anAntenna . 

tm := Transact ionManager 

runAsNewTransaction : 

[ anMMU changeFrequencyto: newFreq ] 
id: * controller=>anMMU. changeFreq’ 
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Evacs Simulation in SmallTalk 
(alternative implementation of centralController.changeFreq) 

parent: current TM 

receiver: anMMU. 

success := ( (tm status) = #completed ) . 

( simWindow textOut: ('transaction success: (success printstring)) ). 

"to differentiate the MMUs from the antenna manager if the mmu fails, it 
is renentered into the parent transaction with a dummy value of 000Hz " 
(success) 
if False: [ 

( anMMU enter: currentTM ) . 

( anMMU changeFrequencyto: ' 000Hz' ) ] . 

tm := TransactionManager 

runAsNewTransaction : 

[ antennaMgr changeAntennasTo: newFreq 
for : mmuNum ] 

id: 1 controller=>anMMU. changeFreq 1 

pare nt : curr e nt TM 

receiver : antennaMgr . 
success := ( (tm status) = #completed ) . 

( simWindow textOut: ('transaction success: 1 , (success printstring)) ). 

( simWindow control lerFreqChangedto: newFreq ) . 

i i 
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Evacs Simulation in SmallTalk 
Smalltalk Application Definition 

"construct application" 

( (Smalltalk at: #Application if Absent: []) 

isKindOf: Class ) if True: [ 

( (Smalltalk at: #Application) for: 1 .Evacs Sim 1 ) 
addClass : EvacsRoot; 
addClass : Transact ionManager; 
addClass : Transact ionParticipant ; 
addClass: PermanentStore; 
addClass : EvacsStack; 
addClass: Evacs; 
addClass : SimWindow; 
addClass: TextDisplayer; 
addClass : TextDi splay Pane ; 
addClass: CentralController; 
addClass: MMU; 
addClass : AntennaMgr ; 
addClass : Antenna; 
comments: nil; 
initCode: nil; 
finalizeCode : nil; 
s t ar t UpCode : ni 1 

] 
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